Wasmtime 40 #562
Draft
Wasmtime 40 #562
+124
−127
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
Author
|
I've opened bytecodealliance/wasmtime#12284 upstream for the |
Collaborator
Author
|
A fix for that was merged but we'll need to a wait for a release that contains that fix before we can update Wasmtime. |
Collaborator
Author
|
The fix is scheduled to ship as part of Wasmtime 41 which should be ready in roughly eleven days. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This isn't ready to merge due to open questions about memory tracking.
image_rangechanged here on line 685 so it now only returns the size of the.textsection in the ELF binary instead of the whole mmap'd file. The.textsection is empty if the Wasm file has no functions. We were using the value returned byimage_rangeto report an increase in memory usage to the Ruby GC. The implementation here will continue to track memory allocated for code and linear memory. However, memory physically allocated as part of allocating an anonymous mmap or reading a file-based mmap for the data segments, traps, dwarf symbols, and other sections won't be tracked. I can't find an equivalent API to get the size of the mmap other than performing a serialization of the module and checking its size which is very inefficient from a speed and memory perspective.